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Abstract 

In this paper, we separately design the decorated logic with respect to 
the state and the exception effects. Then, we combine two logics to be 
able to establish small-step semantics of IMP imperative language with 
exceptional abilities, in a decorated setting. We implement the decorated 
framework in Coq and certify program equivalence proofs written in that 
context. 

Keywords: Decorated logic, proofs of programs, proof verification, Coq. 


1 Introduction 

In mostly used imperative programming languages (such as C/C-I-+ and Java), 
computational effects do exist. With no doubt, they bring an ease and ffexibility 
to the coding process. However, the problem becomes explicit when to prove the 
properties of programs involving effects. The major difficulty in such kind of a 
reasoning is the mismatch between the syntax of operations with effects and their 
interpretation. Typically, a piece of program with arguments in X that returns 
a value in Y is not interpreted as a function from V to V due to the effects. 
The best-known algebraic approach to the problem was initiated by Moggi and 
implemented in Haskell. There, the main focus is to interpret programs with 
effects through the monads: the interpretation looks like a function from X 
to T{Y) where T is a monad. This approach has been extended to Lawvere 
theories and algebraic handlers [10, 11] while there are some others relying 
on effect systems [8, 12] or Hoare Logic [13]. In [6] Duval et al. proposes 
yet another approach where algebraic theories and effect systems are mixed 
by adding decorations to the terms and equations keeping their interpretations 
close to syntax in reasoning with effects. In this paper, we first introduce small- 
step semantics for IMP with exceptional abilities (IMP-|-Exc). This follows the 
same approach given in [7]. Then, Duval’s decorated logic has been designed 
for the state and the exception effects, first separately then combined. The 
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combination here means “merging” the behind logics. Next, we establish small- 
step semantics of IMP-|-Exc over the combined decorated settings. There, we are 
able to cope with termination-guaranteed programs. We illustrate the program 
equivalence proofs within that context and certify proofs with the Coq Proof 
Assistant. 


2 IMP with exceptional abilities 

IMP is a standard imperative programming language. It natively provides 
global variables of type integer, standard integer arithmetic and boolean expres¬ 
sions enriched with a set of commands that is made of do-nothing, assignment, 
sequence, conditionals and looping operations. Below, we detail the syntax 
where n represents a constant integer term while x is an integer global variable. 
Note also that abbreviations aexp and bexp respectively denote arithmetic and 
boolean expressions as well as cmd stands for commands. 

aexp: ai a.2 ::= n | x | ai -|- a2 | ai x a2 

bexp: bi b2 ::= true | false | ai = a2 | ai 7^ a2 | ai > a2 | ai < a2 | 
bi A b2 I bi V b2 

cmd: Cl C2 ::= skip | x := e | ci; C2 | if b then ci else C2 | while b do ci 
Figure 1 : Standard IMP syntax 

Neither arithmetic nor boolean expressions are allowed to modify the state: they 
are either pure or read-only. Indeed, small-step semantics for expressions is a 
total function of the form: |exp] x s ^ exp. It constitutes a new expression out 
of an input expression and the current state. We recursively define it as follows: 


H(s) =n 
|xl(s) = a(x) 

|expi op expsKs) = [expi|(s) |op| |exp2](s) 


Figure 2 : Small-step semantics for expressions 

where |op] stands for natural semantics of any syntactically well-defined arith¬ 
metic or boolean operation. For instance, no matter the current state s, the 
expression |5 -b 4 ](s) will evaluate into 9 . Note that constant terms are pure. 
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(skip) 


(condi) 


s, (SKIP; c) s, c 
(assign) 


(sequence)- 


s,ci s',c'i 


,,(ci;c2) s',(c;;c2) 


s, (x := a) s{a: ■<— |a](s)}, SKIP 


|bl(s) true 


(cond2)- 


|b]|(s) = falE 


s, (cond b Cl C2) s, Ci ^ s, (cond b Ci C2) s, C2 

^ W(s)=true 

(WnilGi )- - -r--r 

s, (while b do c) s, (c; while b do c) 

|b](s) — false 


(while2 


s, (while b do c) s,SKIP 


Figure 3 : Small-step semantics for commands 

The small-step semantics of commands is also a total function defined by the 
judgment s x c -w s' x c'. That is to say, in the state s, execution of the 
command c will change the state into s' and it remains to execute c'. Details 
can be found in Fig. 3 . It remains to note that a command c at some state 
s terminates if there exists a state s' such that s, c s', SKIP after a finite 
number of execution steps. Else if such a state s' does not exist, the command 
c runs forever. Mind also that there is no run-time error since any command 
apart from SKIP is allowed to execute at any state s. SKIP alone is used to 
indicate the final step of some command set. 


2.1 Adding exceptional abilities 

Providing exceptional abilities to the standard IMP language is about enriching 
the command set with throw and TRY/CATCH blocks. In addition to the ones 
in Fig. 1 , we also consider following commands: 

cmd: Cl C2 ::= ... | throw exc | try Ci catch exc => C2 

Figure 4 : Syntax for additional commands 

where exc is an exception name of a new type EName. There might be different 
exception names but EName is the only type within the context that we introduce 
in this paper. The small-step semantics for throw and TRY/CATCH commands 
are detailed below: 
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(throw)----- 

s, (throw exc; c) s, throw exc 


(tryi) 

(try2) 


s, try SKIP catch exc c ^ s, SKIP 


(trya) 


s, try (throw exc) catch exc c s, c 
exci exc2 : EName exci ^ exc2 
s,try (throw exci) catch exc2 => c -w s, throw exci 


Figure 5: Small-step semantics for additional commands 

Exceptional commands are pure with respect to the state effect: they neither 
use nor modify the program state. However, they introduce another sort of com¬ 
putational effect: the exception. In prior, we stated that the command SKIP 
alone indicates the termination of a program. Now, we extend this by stating: 
throw exc is also an end but an exceptional end. 


Recall that the new language is abbreviated as “IMP-|-Exc” and the idea is to 
certify equivalences between programs written in that language. To this extend. 
Section 3 and Section 4 respectively study decorated logics for the state and the 
exception which are combined in Section 5. Einally in Section 6, we translate 
IMP-pExc semantics into decorated settings enriched with an implementation 
in Coq. There, we give a bunch of examples of equivalent code blocks with 
certified equivalence proofs. One of the main examples involves a program with 
an infinite loop inside the try block in which an exception is thrown. As soon 
as the exceptional case is met, the program terminates the loop, recovers the 
exception and continues with an ordinary execution. We will prove that such a 
program has both result and effect equivalence with another one (just made of 
assignments) up to the state and the exception. 


3 Decorated Logic for the state 

Even though it is not syntactically mentioned, the usage/modification of the 
memory state is allowed in imperative languages. For instance, a C function 
may look up the value of a variable as well as another can modify it. That is an 
ease in coding but in order to prove correctness of programs with such abilities, 
one has to revert an explicit usage/manipulation of the state. Therefore, any 
access to the state is treated as a computational effect: a syntactical term 
f : X ^ Y is not interpreted as / : X —E unless it is pure. Indeed, a term 
which reads the program state has instead the interpretation: f : X x S ^ Y 
while another term which updates the state is interpreted as: f:XxS^YxS 
where ‘x’ is the product operator and S is the set of possible states. In [4], we 
proposed a formal system to prove program properties involving the state, while 
keeping the memory accesses and manipulations implicit. As in [1], decorated 
logics for states are obtained from equational logics by classifying terms and 
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equations. Terms are classified as pure terms, accessors or modifiers, which is 
expressed by adding a decoration or superscript, respectively (0), (1) and (2): 
the decoration of a term (or an equation) characterizes the way it may interact 
with the state. The decoration ( 0 ) is reserved for pure terms, while ( 1 ) is for 
read-only {accessor) and ( 2 ) is for read-write {modifier) terms. Equations are 
classified as strong or weak equations, denoted respectively by the symbols = 
and Weak equation relates only the returned values, while strong equation 
relates both values and the state effect. Let us start with the descriptions of 
main features: syntax and rules. 

3.1 Syntax and rules 

Each type is interpreted as a set. In Fig. 6, 1 is the set of singleton while Vi is 
the set of values that can be stored in any location i. Terms represent functions; 
they are closed under composition and “pairs”, tti and 7r2 represent the canon¬ 
ical projections with ( )x: X ^ 1 being the canonical empty pair for each type 
X. The basic interface functions are lookup i: 1 —Vi and update i: Vi ^ 1 . 
Fundamentally, lookup reads the value stored in a given location while update 
stands to modify it. As mentioned, decorations are used to express the state 
interaction of a given term. In particular, id*-°),7ri°\ and ( are pure. 
lookup(^) is an accessor while update^^^ is a modifier. The usage of decora¬ 
tions provides a new schema where term signatures are constructed without 
any occurrence of the state set. So that signatures are kept close to syntax. 
In addition, decorations give us the flexibility to cope with several interpreta¬ 
tions of the state: any proof in decorated settings is valid for different state 
interpretations. 


Syntax : 


Types: t 

:: — A|B|-'-|'tX't|lL|Vi s.t.iGLoc 

Terms: f 

::= id 1 f of 1 (f,f) 1 TTi 1 TTz 1 ( ) 1 


lookup i: 1 —^ Vi 1 update i: Vi —>■ 1 

Decoration for terms: (d) 

::= (0)1 (1)1(2) 

Equations: e 

::= f = f 1 f - f 


Figure 6: Syntax for the state 


The intended model is built with respect to the set of states, denoted S, which 
never appears in the syntax. A pure term p^^') : A —>■ F is interpreted as a 
function p : A —>■ F, an accessor : A —>■ F as a function a : X x S ^ Y 
and a modifier : A —>■ F as a function m : X x S ^ Y x S. Obviously, 
pure terms can be seen as accessors and accessors as modifiers on demand. For 
instance, this allows term compositions to be directly done without recalling the 
Kleisli composition. The complete characterization is given in [I] . 
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Rules: 

(equiv=), (subs=), (repl=) for all decorations 

(equiv^), (subs^) for all decorations, (repl,^) only when replaced term is 


(unit^) 

(axi) 

(ax2) 

(eqi) 

(eq2) 

(eqa) 

(pairi) 


/(2): X ^ 1 
f-{)x 


(=-to-~) 


/(2)^ 


( 2 ) 


pure 


f ^ g 


lookup i o update i ^ idv 

for each pair of locations (i, j) s.t. i 7^ j 

lookup i o update j ~ lookup i ° ()v 

Ad-i) ^ Ad2) 

^ ^ only when di < 1 and ^2 < 1 






( 2 ) / \( 0 ) „ .( 2 ) _ / \( 0 ) ^ ,( 2 ) 


fl = /2 

for each loc. i, f[^\ f^'^: X ^ 1 lookup o ^ lookup 


o/: 


( 2 ) 


/f ^; X ^ r f:f> -.x ^ z 

TTl O {/l,/2) -- fl 


( 2 ) . 


/l=/2 

(pair2) 


: X ^ y : X 

7r2 O {/l, /2) = /2 


( 2 ) . 


Figure 7 : Rules for the state 

As stated in Fig. 7 , given syntax is enriched with a set of rules with a special 
focus on decorations. Strong equations form a congruence while weak equations 
do not: the replacement rule holds only when the replaced term is pure. The 
fundamental equations for states are provided by the rules (axi) and (ax2). With 
(axi), we have lookup o update ^ idv^°^. This means that updating 
the location i with a value v and then observing the value of the location does 
return v. Clearly this is only a weak equation: its right-hand side does not 
modify the state while its left-hand side usually does. With (ax2), lookup o 
update lookup 1*^^^ o ( we assume that updating the location j 

with a value v and then reading the content of location i would return the same 
result with first forgetting the value v then observing the content of location 
i. They definitely have different effects on the state. Mind also that this 
assumption is valid when i 7^ j. There is an obvious conversion from strong to 
weak equations (=-to-^), any term f: X —^ 1 with no result returned (void) is 
said to have an evident result equivalence with the canonical empty pair ( )x by 
(unit.^). In addition strong and weak equations coincide on accessors by rule 
(eqi). Two modifiers fi\f2'-X^Y modify the state in the same way if 
and only if ( )y o /i = ( )y o /2 : X — 1 , where {)y ■ Y throws out the 
returned value. Then weak and strong equations are related by the property 
that fl = fl if and only if /i - fi and ( )y o /i = ( )y o fi, by rule (eq2). For 
each location i, this can be expressed as a pair of weak equations fi ^ /2 and 
lookup i o ( )y o fl lookup i o ( )y o /2, by rule (eqa). With (pahi) and 
(pair2) categorical pairs are characterized: the pair structure (/i, /2) cannot be 
used while both fi and /2 are modifiers, since it would lead to a conflict on 
the returned result. However, it can be used when only fi is an accessor. By 
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(pairi), we state that (/i,/ 2 )^^^ has only result equivalence with and both 
result and effect equivalence with by (pair 2 ) . 

3.2 Decorated logic for the state in Coq 

We represent the set of memory locations by a Coq parameter Loc; Type. 
Since memory locations may contain different types of values, we also assume 
an arrow type Val : Loc Type that is the type of values contained in each 
location. 

Parameter Loc: Type. Parameter Val: Loc Type. 

Figure 8: Locations and values in Coq 

The terms of the logic are defined through the inductive type named term which 
establishes a new Type out of two input Types. The type term Y X is dependent. 
It depends on the Type instances X and Y and represents the arrow type: X —Y. 
The constructor tpure takes a Coq side (pure) function and drops it into the 
decorated environment. So that pure terms as id, 7ri,7r2 and ( ) are covered 
within the scope of tpure. 


Inductive term: Type Type —¥ Type : = 

I comp : V {X Y Z: Type}, term X Y —)■ term Y Z 
term X Z 

I pair : V {X Y Z: Type}, term X Z —>■ term Y Z 
term (XxY) Z 

I tpure : V {X Y: Type}, (X —>■ Y) —)■ term Y X 
I lookup : V i:Loc, term (Val i) unit 
I update : V i:Loc, term unit (Val i). 

Infix ”o” := comp (at level 60). 


Inductive kind := pure | ro | rw. 

Inductive is: kind — V X Y, term X Y —)• Prop := 
I is.tpure: V X Y (f: X ^ Y), 

is pure (@tpure X Y f) 

I is_comp: V k X Y Z (f: term X Y) 

(g: term Y Z), is k f ^ is k g ^ is k (f o g) 

I is_pair: V k X Y Z (f: term X Z) (g: term Y Z), 
is k f ^ is k g — )• is k (pair f g) 

I is_lookup: V i, is ro (lookup i) 

I is_update: V i, is rw (update i) 

I is_pure_ro: V X Y (f: term X Y), 
is pure f ^ is ro f 
I is_ro_rw: V X Y (f: term X Y), 
is ro f ^ is rw f. 


Figure 9: Terms and decorations for the state in Coq 

Decorations are enumerated: pure (0), ro (1) and rw (2) and inductively as¬ 
signed to terms via the new type is. It builds a proposition out of a term 
and a decoration. I.e., Vi : Loc, is ro (lookup i) is a Prop instance, ensur¬ 
ing that lookup i is an accessor. Last two constructors define the decoration 
hierarchies. 

Definition id {X: Type} : term X X := tpure id. 

Definition pil {X Y: Type} : term X (XxY) tpure fst. 

Definition pi2 {X Y: Type} : term Y (XxY) tpure snd. 

Definition forget {X} : term unit X ;= tpure (fun _ =>■ tt). 

Definition constant {X: Type} (v: X): term X unit := tpure (fun _ => v). 

Definition perm {X Y}: term (XxY) (YxX) pair pi2 pil. 

Definition invpil {X}: term (Xxunit) X := pair id forget. 

Figure 10: Some derived terms for the state in Coq 

Fig. 10 includes derivation of some terms that we latter use. I.e., ( ) is handled 
via tpure and called forget. Besides, we state the rules, in Fig 11, up to weak 
and strong equalities by defining them in a mutually inductive way: mutuality 
here is used to enable the constructors with both weak and strong equalities. 
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Reserved Notation ”x == y” (at level 80). Reserved Notation ”x ~ y” (at level 80). 
Inductive strong; V X Y, relation (term X Y) : = 

I subs-repl=: V X Y Z, Proper (©strong X Y ==> ©strong Y Z ==> ©strong X Z) comp 
I eqi: V X Y (f g: term X Y), is ro f —)■ is ro g ^ f ~ g —>■ f —— g 

I eq 2 : V X Y (f g; term Y X), (forget o f —— forget og)^f~g—J-f —— g 

I eqs: V X (f g; term unit X), (V i: Loc, lookup i o f ~ lookup i o g) — f == g 

I pair 2 : V X Y’ Y (fl; term Y X) (f2: term Y’ X), is ro fl pi2 o pair fl f2 —— f2 

with weak; V X Y, relation (term X Y) : = 

I subs~; V A B C, Proper (©weak C B ==> ©strong B A ==> ©weak C A) comp 

I repl^; V A B C (g: term C B), (is pure g) —¥ Proper (©weak B A ==> ©weak C A) (comp g) 

I unit^: V X (f g: term unit X), f ^ g 

I axl: V i, lookup i o update i ~ id 

I ax 2 : V i 1 , i^^i lookup i o update i ~ lookup i o forget 

I ^-to-~: V X Y (f g: term X Y), f = g ^ f ~ g 

I pairi: V X Y’ Y (fl; term Y X) (f2: term Y’ X), is ro fl —>■ pil o pair fl f2 ~ fl 

where ”x == y” (strong x y) and ”x ~ y” ;= (weak x y). 

Figure 11: Rules for the state in Coq 

One can simply derive the reflexivity property up to weak equality: given f = f, 
it suffices to convert strong equality into weak by (=-to-~). Now; we can form 
the primitive properties of the state structure as in [10] but this time with 
decorations. 

1. annihilation lookup-update Vi e Loc, update i^^^ o lookup i^^^ = id unit^®^ 

2. interaction lookup-lookup Vi e Loc, lookup i^^^ o forget (Val i)*'®^ o lookup i^^^ = 

lookup i^^^ 

3. interaction update-update Vie Loc, update i*'^^ o pi2*'®^ o pair (update i,id (Val i))^^^ = 
update i^^^ o pi 2 ^*^^ 

4. interaction update-lookup Vie Loc, lookup i^^^ o update i^^^ ~ id (Val i)^^^ 

5. commutation lookup-lookup Vi ^ j e Loc, pair(id (Val i), lookup j)^^^ o lookup i^^^ = 
perm j i^°^ o pair(id (Val j), lookup i)^^^ o lookup 

6 . commutation update-update V i j e Loc, update opi2^®^ opair(update i, id (Val j))^^^ = 
update i^^^ opil^^^ o pair(id (Val i), update 

7. commutation update-lookup V i 7 ^ j e Loc, lookup o update i^^^ = pi2^°^ o 

pair(update i, id (Val j))^^^ o pair(id (Val i), lookup j)^^^ o invpil^®^ 

Figure 12: Primitive properties of the state 

Then, we prove such properties within the decorated context and get these 
proofs certihed by Coq. In [3], we detail the implementation as well as the Coq 
certified proof of commutation update-lookup. For the definitions of terms 
invpi and perm one can refer back to Fig. 10. The complete Coq library with all 
certified proofs can be found on https : //forge . imag. fr/frs/download. php/649/STATES- 0.8 . tar 


4 Decorated Logic for the exception 

Exception handling is provided by most modern programming languages. It 
allows to deal with anomalous or exceptional events which require special pro¬ 
cessing. That brings a flexibility to the coding but in order to prove the correct¬ 
ness of such programs one has to revert an explicit interaction with exceptions. 




Therefore, any interaction with exceptional cases is treated as a new sort of com¬ 
putational effect: a term f : X ^ Y is not interpreted as a function f : X ^ Y 
unless it is pure. Indeed, a term which may raise an exception is instead in¬ 
terpreted as a function f : X ^ Y + E and similarly, a term which may catch 
an exception is interpreted as a function f: X + E^Y + E where ‘-f’ is 
disjoint union operator and E is the set of exceptions. Moreover, it has been 
shown in [2] that the core part of this proof system is dual to one for the state 
which is explained in Section 3. As in [3], decorated logics for exception are 
obtained from equational logics by classifying terms and equations. Terms are 
classified as pure terms, propagators or catchers, which is expressed by adding a 
decoration or superscript, respectively (0), (1) and (2): the decoration of a term 
(or an equation) characterizes the way it may cope with exceptional cases. The 
decoration (0) is reserved for terms which are pure, while (1) is for throwers and 
(2) is for catchers. Equations are classified as strong or weak equations, denoted 
respectively by the symbols = and Weak equation relates the ordinary cases 
in programs, while strong equations relates both ordinary and exceptional cases. 
Let us describe the main features of the logic: syntax and rules. 

4.1 Syntax and rules 

The full syntax is declared in Fig. 13 where 0 is the empty type while Vg repre¬ 
sents the set of values which can be used as arguments for the exceptions with 
name e. Terms represent functions; they are closed under composition and “co¬ 
pairs” (or case distinction), ini and inr represent the canonical inclusions into 
a coproduct (or disjoint union). The basic functions for dealing with exceptions 
are tag e: Vg —>■ 0 and untag e: 0 —> Vg. A fundamental feature of the mech¬ 
anism of exceptions is the distinction between ordinary (or non-exceptional) 
values and exceptions. While tag e encapsulates its argument (which is an ordi¬ 
nary value) into an exception, untag e is applied to an exception for recovering 
this argument. The usual throw and try/catch constructions are built from 
the more basic tag e and untag e operations [3]. The term downcast takes an 
input term f and behaves exactly as f on ordinary arguments, if the argument 
is exceptional then it enforces f to propagate it (in case f might catch it). As 
mentioned, we use decorations on terms for expressing how they interact with 
the exceptions. In particular, inl*^°\ inr^^^ and [ are pure. Clearly 

tag and downcast*^^) are throwers while untag is a catcher. A thrower 
may throw exceptions and must propagate any given exception, while a catcher 
may recover from exceptions. Using decorations provides a new schema where 
term signatures are constructed without any occurrence of a “type of excep¬ 
tions”. Thus, signatures are kept close to the syntax. In addition, decorating 
terms gives us the flexibility to cope with more than one interpretation of the 
exceptions. This means that with such an approach, any proof in decorated 
logic is valid for different implementations of the exceptions. 


9 


Syntax: 

Types: t 
Terms: f 

Decoration for terms: (d) 
Equations: e 


A|B|---|t+t|0|Ve s.t.egEName 

id I f o f I [f I f ] I ini I inr I [ ] I 
tag e: Ve ^ 0 I untag e: 0 —>■ Vg | 

(0) I (1) I (2) 
f = f I f ~ f 


Figure 13: Syntax for the exception 

The intended model is built with respect to the set of exceptions, denoted E, 
which never appears in the syntax. It interprets each type X as a set X, each 
pure term : X —>■ T as a function u : X ^ Y, each propagator : X ^ Y 
as a function a : X ^ Y + E and each catcher : X ^ Y as a function 
f : X + E ^ Y + E. The complete characterization is given in [3]. 


Rules: 

(equiv=), (subs=), (repl=) for all decorations 

(equiv,^), (repfo) for all decorations, (subs,^) only when substituted term 




(eaxi) 

(eax2) 

(eeqi) 

(eeq2) 

(eeqs) 


/' 


X 




(downcasts 


downca: 


untag e o tag e ~ idv 

for each pair of exception names (ei, 62 ) s.t. ei ^ 62 


n 


(di) 


/: 


untag ei o tag 62 

id2) 


Otag 62 


fid. 

Jl ) 12 


= J2 
: Y 


only when di < 1 and d 2 < 1 


X f, 


( 2 ) 


/f 


( 2 ) 




h = h 


for exc. name e, : 0 —X f[^^ o tag e 


.(1) 




( 2 ) 4 . 

2 o tag 


(copahi) 


/f ^ : X ^ y /f) ■ 


: Z ^Y 


[fi I /2] o ini ~ fi 


h = h 

(copair2) 


-.X^Y f. 


( 2 ) . 


[/i I M 


= t 


IS pure 
X 


t/~/ 


4 ( 1 ) 


Y 


Figure 14: Rules for the exception 


As stated in Fig. 14, a set of rules enriches the syntax with a special focus on dec¬ 
orations. Strong equations form a congruence while weak equations do not: the 
replacement rule holds only when the replaced term is pure. Since, (downcast 
f) and f behave the same on ordinary arguments, they are weakly equal ensured 
by the rule (donwcast,,^). The fundamental equations for states are provided by 
the rules (eaxi) and (eax 2 ). With (axi), we have untag otag ~ idv*-®^. 
This means that encapsulating the argument with an exception of name e 
followed by an immediate recovery would be equivalent to “doing nothing” 
with respect to the ordinary values. Clearly this is only a weak equation: its 
right-hand side has no exceptional case while its left-hand has. With (eax 2 ), 
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untag o tag 62 ^^^ ^ [ ]y o tag 62 *-^^ we assume on the left that encap¬ 
sulating an argument with an exception of name 62 and then recovering from 
a different exception of name ei would just lead 62 to be propagated. Whilst 
on the right, the argument is encapsulated with 62 with no recovery attempt 
afterwards. Thus, they behave different on exceptional values but the same on 
ordinary ones: the equality in between is weak. There is an obvious conversion 
from strong to weak equations (=-to-~), any term f: © —>■ X with no input pa¬ 
rameter is said to have an equivalence on ordinary values with the canonical 
empty copair [ ]x by (empty.^). In addition strong and weak equations coincide 
on propagators by rule (eeqi). Two catchers : X ^ Y have the same 

effect up to the exceptional values if and only if /i O []y = f2 O [] Y ■ © ^ X. 
Then weak and strong equations are related by the property that /i = /2 if 
and only if /i ^ /2 and fi o []y = f 2 o[]y, by rule (eeq 2 ). For each excep¬ 
tion name e, this can be expressed as a pair of weak equations /i ^ /2 and 
fi o[]y o tag e ~ /2 o [ ]y o tag e, ensured by the rule (eeqa). With (copairi) 
and (copair 2 ) categorical copairs are characterized: the copair structure [fi \ f 2 ] 
cannot be used while both fi and /2 are catchers, since it would lead to a con¬ 
flict when the argument is an exception. However, it can be used when only fi 
is a propagator. With (copairi), we state that ordinary arguments are treated 
by [fi I as they would be by and with (copair 2 ), both ordinary and 

exceptional arguments are treated by [fi \ f 2 ] as they would be by . 

4.2 Decorated logic for the exception in Coq 

Coq implementation follows the same approach with the one for the state. We 
represent the set of exception names by a Coq parameter EName: Type, we 
assume an arrow type Val : EName —>■ Type which is the set of parameters for 
each exception name. Then, we inductively define terms and assign decorations: 

Parameter EName: Type. Parameter EVal: EName —>• Type. 

Figure 15: Exception names and values in Coq 
We use keywords pure, propagator and thrower instead of (0), (1) and (2). 


Inductive term: Type —¥ Type Type : = 

I downcast : V{X Y} (f: term Y X), term Y X 
I copair : V {X Y Z: Type}, term Z X —>■ term Z Y 
-)■ term Z (X + Y) 

I tpure : V {X Y: Type}, (X —>■ Y) —)■ term Y X 
I tag ; V e:EName, term Empty_set (EVal e) 

I untag ; V eiEName, term (EVal e) Empty_set. 


Inductive kind := pure | propagator | catcher. 

Inductive is: kind — >• V X Y, term X Y — >■ Prop ; = 
I is_downcast: V X Y (f; term Y X), 

is propagator (downcast f) 

I is.tpure: V X Y (f: X ^ Y), 

is pure (@tpure X Y f) 

I is_copair: V k X Y Z (f: term X Z) 

(g: term Y Z), is k f — >• is k g — )• is k (pair f g) 
I is_tag: V i, is propagator (tag e) 

I is_untag: V i, is catcher (untag e) 

I is_pure_propagator: V X Y (f: term X Y), 
is pure f ^ is propagator f 
I is_propagator_catcher; V X Y (f: term X Y), 
is propagator f ^ is catcher f. 


Figure 16: Terms and decorations for the exception in Coq 
Some derived terms including throw and TRY/CATCH blocks are hereby stated: 
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Definition id {X: Type} : term X X := tpure id. 

Definition emptyfun (X: Type) (e; Empty_set) : X := match e with end. 

Definition empty X: term X Empty_set := tpure (emptyfun X). 

Definition ini {X Y} : term (X+Y) X := tpure ini. 

Definition inr {X Y} : term (X+Y) Y ;= tpure inr. 

Definition throw (X: Type) (e: EName): term X unit := (empty X) o tag e. 

Definition TRY_CATCH (X Y: Type) (e:EName) (f: term Y X) (g; term Y unit) 
downcast(copair (@id Y) (g o untag e) o ini o f). 

Definition ttrue ; term (unit+unit) unit ini. 

Definition ffalse : term (unit+unit) unit := inr. 

Figure 17: Some derived terms for the exception in Coq 

The functions ini and inr indicate coprojections. In addition, [ ] is called 
empty, ttrue and ffalse correspond to boolean true and false. The operation 
throw e is just t aging an exception of name e followed by [ which is used to 
bridge the execution to the next command. Within the scope of the intended 
model, it is used to include 0 into 0 + X. To build (TRY f CATCH eg), we 
use copairs to have case distinction: (1) either the term f does not throw an 
exception so that the term g is never triggered. That corresponds to the idy case 
of the copair. (2) or else, the code f throws an exception then through untag e, 
the exception would be recovered (if pattern matching is fine with exception 
names) and execution continues with the term g. The whole TRY — CATCH block 
is either pure (in case no exceptional case has been met) or a thrower/propagator 
(in case, the thrown exception by f has not been caught or a previously thrown 
exception has been propagated). This is ensured the rule (downcast,^). Now; 
we get the rules in Coq: 

Reserved Notation ”x == y” (at level 80). Reserved Notation ”x ~ y” (at level 80). 

Definition pure_id X Y (x y: term X Y) is pure x A x = y. 

Inductive strong; V X Y, relation (term X Y) : = 

I subs-repl=: V X Y Z, Proper (©strong X Y ==> ©strong Y Z ==> ©strong X Z) comp 
I eeqi: V X Y (f g: term X Y), is propagator f ^ is propagator g ^ f ~ g ^ f == g 
I eeq 2 : V X Y (f g: term X Y), (f o empty == g o empty) — >• f ~ g ^ f == g 
I eeqs: V X (f g: term X Empty_set), (V e: EName, f o tag e ~ g o tag e) —>■ f == g 
I copair 2 ; V X Y Z (fl: term Y X) (f2: term Y Z), is propagator fl — )■ pair fl f2 o inr —— f2 
I s-equivi: V X Y (f; term X Y), f == f 

with weak: V X Y, relation (term X Y) : = 

I subs^ : V A B C, Proper (©weak C B ==> @pure_id B A ==> ©weak C A) comp 
I repl,-.^ : V A B C, Proper (©strong C B ==> ©weak B A ==> ©weak C A) comp 
I empty V X (f g: term X Empty_set), f ~ g 
I donwcasto.,; V X Y (f: term Y X), downcast f ~ f 
I eaxl: V e, untag e o tag e ~ id 

I eax2: V ei e 2 , ei:^e 2 untag ei o tag e 2 ~ empty o tag e 2 
I =-to-~: V X Y (f g: term X Y), f —— g ^ f ~ g 

I copairi; V X Y Z (fl: term Y X) (f2; term Y Y), is propagator fl — )■ copair fl f2 o ini ~ fl 

where ”x == y” := (strong x y) and ”x ~ y” := (weak x y). 

Figure 18: Rules for the exception in Coq 
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( 0 ) 


1 . 

2 . 

3. 

4. 

5. 

6 . 


propagator propagates: Vg^^^ : Y —)• X, g*-^^ o [ = [ ]y. 

annihilation untag-tag: tag t*'^^ o untag t^^^ = id 0 ^*^^ 
annihilation catch-raise: (TRY — CATCH f (t ^ (throw t Y)))*'^^ = 

commutation untag-untag: s 7 ^ t, (untag t^^^ + id s^°^) o untag s^^^ = (id t^°^ + untag s^^^) o untag t^^^ 
interaction propagator-throw: g^^^ : Y ^ X, g^^^ o (throw t Y) = (throw t X) 

commutation catch-catch: s / t, (TRY - CATCH f (t ^ g | s ^ h))^^^ = (TRY - CATCH f (s ^ h | t ^ g))^^^ 

Figure 19: Primitive properties of the exception 


After all, we give the properties of the exception followed by the related proofs 
certified in Coq. In [3], we detail the implementation and the certified proof 
of the propagator propagates. The complete Coq library with all certified 

proofs is available on https://forge.imag.fr/frs/download.php/648/EXCEPTI0NS-0. 3 .tar.gz. 


5 Combination: the state Sz, the exception 


In order to formally cope with both the state and the exception effects in the 
same program, one needs to combine the related formal models. For instance in 
Haskell, effects are modeled by monads and combination is done through monad 
transformers. However, here we just merge the related decorated logics. Let us 
start with explanation of the syntax: 


Syntax : 

Types: t 

::= A|B|---|t+t|txt|l|©| 

Terms: f 

s.t.iGLoc 1 s.t.e^EName 

::= id|fof |[f |f]|(f,f)| 

Decoration for terms: (d) 

1 [ ] 1 ( ) 1 ini 1 inr | tti | 712 | downcast | 
lookup i : 1 — ^ Vi 1 update i: Vi — ^ 1 | 
tag e: Vg — >■ 0 1 untag e: 0 — >■ Vg 
::= (0,0) 1 (0,1) 1 (0,2) | (1,0) | (1,1) | (1,2) 

Equations: e 

(2,0) 1 (2,1) 1 (2,2) 

::= f == f 1 f =- f 1 f ~= f 1 f f 


Figure 20: Syntax for the combined state and exception 


Types and terms are simply unionized. The decorations are paired off to cover 
all possible combinations: left component is given up to the state while right is 
to the exception. I.e., says that / is an accessor with respect to the state 

and catcher to the exception. The hierarchies among decorations are preserved: 

, j( 2 ,d) 1 j(d,i) and j(d, 2 } ■ Obviously, we have all possible combinations 
of equalities with preserved hierarchies: (==-to-=~)^^^, (==-to—=) and 




f(di,d2) 
'-tO- = = )- 


(d3,^ 4 ) 


/== 9 


only when di,d2,d3,d4 < 1. Here we form the combined 
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rules: 


1. == relates the properties that are strongly equal both up to the state 

and the exception: (eqi) is now with (eq 2 ) and (eqa) with 

and (pair 2 ) with la addition, (eeqi) with 

(eeq 2 ) and (eeqa) with /fand (copairz) with /f 

2. ~= relates the properties that are weakly equal up to the state: (unit^) is 

now with (axi) and (ax 2 ) with lookup*^^’°\ update^^'®) and (pairi) 

with /<■’“•, /P’^> 

3. relates the properties that are weakly equal up to the exception: 

(empty^) is with (downcasts) with (eaxi) and (eax 2 ) with 

untag(°’2) and (copahi) with /f 

4. relates nothing but the conversions: and =~ can be seen as 


6 IMP+Exc over decorated logic 


Finally, it comes to translate the semantics detailed in Section 2 into the com¬ 
bined decorated settings. Given that IMP only provides the integer data type, 
the values that can be stored in any location i are just integers. So that any 
occurrence of (Val i) in term signatures is replaced by Z. Here, we start with 
expressions and recursively define the translator function dExp. It mainly takes 
an expression and outputs a decorated term of type term Z unit or term IB unit 
depending on the input expression type. Below, we have it recursively defined: 


dExp n 
dExp X 
dExp (f exp) 
dExp (expi,exp2) 


(constant 

(lookup 

(tpure o (dExp exp)^^’*^^ 
(dExp expi,dExp exp2)*'^’®^ 


Figure 21: Translating expressions into decorated settings 

where f is a unary pure term. Besides, we have some additional rules to make 
use of some pure algebraic operations in the decorated setting. Before going into 
the rule details, we define some terms that help to form them: given in Fig. 22, 
Ipi is the syntactical term providing loop iteration(s) together with the rule 
(imp-loopiter) while pbl forms terms of type term (unit + unit) IB for com¬ 
patibility issues in rule statements (imp 2 ) and (imp 4 ). 
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Ipi (b : term unit (unit + unit)) (f : term unit unit) := tpure (Ax : unit.x). 

pbl := tpure (bool_to_two) 

where bool_to_two (b : bool) := (if b then (ini tt) else (inr tt)). 
such that tt : unit and ini, inr : unit —> (unit + unit) 

Figure 22: Additional terms: IMP specific 


(imp — loopiter) 
(impi 


V(b : term unit (unit + unit)) (f : term unit unit) 
Ipi b f == [(ipi b f) o f |id] o b 

Vp, q : Z, (f : Z X Z ^ Z) 


(imp2) 

(imp4) 


tpure f o (constant p, constant q) == (constant f(p,q)) 
Vp, q : Z, (f : Z X Z — >■ B) f (p, q) = false 


pbl o tpure f o (constant p, constant q) == ff alse 
Vp, q : B, (f : B X B —>■ B) f (p, q) = false 
pbl o tpure f o (constant p, constant q) == ff alse 
f:Y^Z g:X->Y 


(imps) 


tpure f o tpure g == tpure (Ax.f (g x)) 
f g : Y —> X (Vx, f X = g x) 


(imp?)- 


tpure f = tpure g 


Figure 23: Additional rules: IMP specific 

In (imp 2 ) and (imp 4 ) by replacing false into true and ffalse into ttrue 
we get (imps) and (imps) that are not explicitly stated here. The fact that 
IMP commands are of type 1 —>■ 1, they will be designed in such a way that 
domains and codomains being set to unit within the decorated scope. Now; 
we recursively define the translator function dCmd which establishes a decorated 
term of type term unit unit, out of an input command: 
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dCmd SKIP 
dCmd (x := a) 
dCmd (ci; C2) 

dCmd (cond b Ci C2) 
dCmd (while b do c) 


dCmd (throw exp) 
dCmd (try Ci catch exp C2) 


(id unit)^°’°^ 
(update o (dExp 

(dCmd C2)^^’°^ o (dCmd 


dCmd Cl 


dCmd C2 


( 2 , 0 ) 


O 


pbl( 0 " 0 ) o (dExp 


(ipi (pbl o (dExp b)) (dCmd c)) o (dCmd c) 


id 


( 2 , 0 ) 


o pbl^'^’*'^ o (dExp 
[ o tag exp^*^’^) 


i( 


id 


C2 o untag exp 


o ini o Ci)(°’^^ 


Figure 24: Translating commands into decorated settings 
Let us take a closer look into conditionals and loops in terms of diagrams: 




Figure 25: (cond b ci C 2 ) and (while b do c) in decorated settings 

there, we use categorical copairs to have case distinction. For instance, in Fig. 25 
on the left, after the condition check if the boolean evaluates into ttrue, then 
we have ci in execution or else C 2 . The only difference on the right is that as 
long as the boolean evaluates into ttrue, c is in execution: diagrammatically, 
it says that the arrow Ipd b c is each time replaced by the whole diagram it¬ 
self. As mentioned, this property is provided by the syntactic term Ipd and the 
attached rule (imp-loopiter). When the boolean evaluates into ffalse, we 
have id forcing the loop to terminate. 

Contrarily, in the translation of throw and try/catch, the basis is the core 
decorated operations for the exception effect. Recall that they are defined as 
they are given in Section 4.2 with a single difference in the signatures: do¬ 
mains/codomains are now set to 1. Below, we have the translation in terms of 
diagrams: 
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1 


1 


tag exp 


^0 


[]i 


4-1 



Figure 26: (throw exp) and (try ci catch exp C 2 ) in decorated settings 
We implement such formalizations in Coq: 


Inductive Exp : Type —>• Type := Fixpoint dExp A (e: Exp A): term A unit := 

I const : V A, A —)• Exp A match e with 

I loc ; Loc —>• Exp Z | const Z n =>■ constant n 

I apply : V A B, (A —^ B) —>• Exp A —>• Exp B j loc x => lookup x 

I pExp : V A B, Exp A Exp B Exp (A x j apply_f x tpure f o (dExp x) 

B). I pExp_X y =>■ pair (dExp x) (dExp y) 

end. 

Figure 27: IMP+Exc expressions in Coq 

Expressions are inductively defined forming a new Coq Type, Exp. Indeed, Exp 
is a dependent type. That means that the type of Exp A depends on the term 
A: Type. Eor instance, when A := B, we build the type for boolean expressions 
while the case A := Z enables us to construct the type for arithmetic expressions. 
Obviously, Exp is polymorphic, too. Speaking of the constructors: an expres¬ 
sion might be a constant term (constructed by const), a variable (by loc), an 
expression with an applied pure term (by apply) or a pair of expressions (by 
pExp). The translation given in Eig. 21 is characterized by the fixpoint dExp. 


A similar idea of implementation follows for the commands: 


Inductive Cmd : Type : = 

I skip : Cmd 

I sequence ; Cmd —¥ Cmd Cmd 
I assign : Loc —>• Exp Z Cmd 
j cond : Exp B —> Cmd Cmd Cmd 
I while : Exp bool Cmd Cmd 
I throw : EName Cmd 

I try_catch : EName Cmd —¥ Cmd —¥ Cmd. 


Fixpoint dCmd (c: Cmd): (term unit unit) : = 
match c with 
I skip (@id unit) 

I sequence cO cl (dCmd cl) o (dCmd cO) 

I assign i a ^ (update i) o (dExp a) 
j cond b c2 c3 => copair (dCmd c2) (dCmd c3) 
o (pbl o (dExp b)) 

I while b c4 ^ (copair (Ipd (pbl o (dExp b)) 
(dCmd c4) o (dCmd c4)) 

(@id unit)) o (pbl o (dExp b)) 

I throw e =>• (throw unit e) 

I try_catch e cl c2 ^ (@TRY_CATCH (dCmd cl) 
(dCmd c2)) 

end. 


Figure 28: IMP+Exc commands in Coq 


In Eig. 28 on the left, we inductively define commands and on the right, re¬ 
cursively translate their behaviors into decorated settings. This translation is 
similar to the one given in Fig. 24, but this time done in Coq terms. Within 
the above context, we retain sufficient material to prove equivalences among 
programs involving not only the state but also the exception effect. 
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6.1 Program equivalence proofs: the state and the excep¬ 
tion 

Here, we exemplify a bunch of program equivalence proofs. Note that for the 
sake of simplicity, we will use Ux, lx, (t op) and (c p) instead of (update 
(lookup (tpure op)*'°’°^ and (constant respectively. 

Remark 6.1. IMP specific properties of the state are slightly different than their 
generic versions given in Fig. 12. The ones we use through the following proofs 
are re-stated below. The full certified proofs can be found in the Cog release: see 
the given link at the end of the section. 

1. interaction update-update Vx G Loc p, q : Z, Ux o (c p) o Ux o (c q) = Ux o (c p) 

2. commutation update-update Vx 7 ^ y G Loc p.q : Z, Ux o (c p) o Uy o (c q) 

= Uy o (c q) o Ux o (c p) 

3. commut at ion-lookup-const ant-update Vx G Loc,p,q € Z, (lx, (c q))ouxO(c p) = ((c p), (c q))o 
Ux o (c p) 

Figure 29: Primitive properties of the state: IMP specific 

Lemma 6.2. For each f (2.°), g(2.o) : Cmd and : bool, let prog3 = (if b 

then f else g) and prog4 = (if b then (if b then f else g) else g). Then 
prog3 == prog4. 

Proof. We first sketch the diagrams of both programs as below: 


1 1 




where k = (if b then f else g). Thus, [f |g] o pbl o c b = [k|g] opbl o c b. 
The proof proceeds by the induction on b. If b = false, by unfolding pbl and 
(c false), we have [ f | g ] o tpure(bool_to_two) o tpure(Ax : unit.false) = 

[ k I g ] o tpure(bool_to_two) o tpure(Ax : unit.false). We rewrite (imps) 
to get [ f I g ] o tpure(Ax : unit.bool_to_two false) = [ k | g ] o tpure 
(Ax : unit.bool_two false). Now, we cut tpure (Ax : unit.bool_to_two false) 
== inr. So that we obtain [ f | g ] o inr == [ k | g ] o inr. Then, we 
use (copair 2 ), and finally have g == g. It remains to show tpure (Ax : unit. 
bool_to_two false) == inr. By simplifying tpure (Ax : unit, bool _to _two 
false) and unfolding inr, we have tpure (Ax : unit, inr x) == (tpure inr). 
Now, we apply (impr) and get Vx : unit, inr x = inr x. 
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Else if b = true, by following above procedure with true (instead of false) 
we first handle [f |g] o ini == [k|g] o ini and then freely convert == into =~. 
There, rewriting the rule (copairi) yields f =~ k. We unfold k with b = true. 
Thus f =~ [ f I g ] o ini. Now by rewriting (copairi), we have f f. □ 

Lemma 6.3. For each x : loc, let prog5 = (x := 2; while (x < 11) do x := 
X + 4;) and prog6 = (x := 14). Then prog5 == prog6. 

Proof. In the proof structure, we first deal with the pre-loop assignments and the 
looping pre-condition. Since it evaluates into true, in the second step we identify 
things related to the first loop iteration. The third step primarily studies the 
second and then the third loop iteration after which the looping pre-condition 
switches to false. Finally, we explain the program termination. Let us sketch 
the diagram of progB: 


Ipi b f 



where f = (x := x + 4) and b = (x < 11). 

1. So that we have (|lpi b f) o f | id^L j o pbl o (^'tpiir’e ) O (lx,(c 11)) 
o Ux o (c 2) == Ux o (c 14). Let us try to simplify it as far as possible. 
By commutation — lookup — constant — update, we obtain [ (ipibf) o 
f I idi ] o pbl o (tpure <) o((c 2), (c 11)) o Ux o (c 2) == Ux o (c 14). By 
rewriting (imp 2 ): [dpi b f) o f |idi] o ttrue o Ux o (c 2) == Ux o (c 14). 
We first convert == into =~ and then rewrite (copairi). So that we 
have (ipi b f) o f o Ux o (c 2) =~ Ux o (c 14) which unfolds (ipi b f) 
o Ux o (tpure -f) o (lx, c 4) o Ux o (c 2) =~ Ux o (c 14). Since, there is 
no exceptional case, we are back to ==. By rewriting commutation 
—lookup —const ant —update, we obtain (ipi b f) o Ux o (tpure -f) 
o (c 2, c 4) o Ux o (c 2) == Ux o (c 14). The rule (imp 2 ) gives (ipi 
b f) o Ux o (c 6) o Ux o (c 2) == Ux o (c 14). Now, by the lemma 
interaction-update-update, we get (ipi b f) o Ux o (c 6) == Ux o 
(c 14). 

2. We can rewrite (imp-loopiter) and get [ (Ipi b f) o f | idi ] o pbl 
o (tpure <) o (lx, (c 11)) o Ux o (c 6) == Ux o (c 14). In the second 
iteration with the above procedure, we have [ (Ipi b f) o f | idi ] ° pbl 
o (tpure <) o (lx, (c 11)) o Ux o (c 10) = = Ux o (c 14). 


19 



3. The third iteration yields [ dpi b f) o f | id^] o pbl o (tpure <) o 
(lx, (c 11)) o Ux o (c 14) == Ux o (c 14). Now; again by rewriting the 
lemma commutation-lookup-constant-update, we have [ dpi b f) o 
f I idi] o pbl o (tpure <) o ((c 14), (c 11)) o Ux o (c 14) == Ux o (c 14). 
We rewrite (imp 2 ) and then obtain [ dpi b f) o f | idi] o inr o Ux o 
(c 14) == Ux o (c 14). 

4. Finally, it suffices to rewrite (copair 2 ); idi o Ux o (c 14) == Ux o (c 14). 

□ 

Lemma 6.4. For each x y : Loc, e : EName, let prog3 = (x := 1; y := 20; try 
((while (tt) do (if (x <= 0) then (throw e) else (x := x — 1)))) catch (e 
(y := 7))) and prog4 = (x := 0; y := 7) . Then progS == prog4. 

Proof. Within the below enumerated proof structure, we first tackle with the 
downcast operator. The second task is to deal with the first loop iteration 
which has the state but no exception effect. In the third, we study the second 
iteration of the loop where an exception is thrown. Finally, in the fourth step, 
we explain the loop termination followed by the exception recovery and the 
program termination. Let us now sketch the diagram of progS: 



where b = (x <= 0 ), Cq = (x := 0 ;y := 20 ), Ci = (if(x <= 0 ) then(throw e) 
else (x := X — 1)), Ci = (x := x — 1) and C 3 = (y := 7). 


1. We have 


i ( [ i 


idi C 3 o untag e I o ini o 


o ttrue 


(ipi ttrue Cl) o [ []i o 

^ o Uy o (c 20 ) o Ux o (c 1 ) == 
Uy o (c 7 ) o Ux o (c 0 ). We first convert == into =^, then rewrite the 
(downcasts) rule and get [ idi | C 3 o untag e ] o ini o T (ipi ttrue ci) 


tag e C 2 I o pbl o b 


idi 


tag e C 2 o pbl o b 


idu 


o ttrue o Uy o (c 20 ) o Ux o (c 1 ) 


=~ Uy o (c 7) o Ux o (c 0). Rewriting commutation-update-update, on 
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both sides, gives [idi|c 3 o untag e oinl o (ipi ttrue Ci) o [[ o tag i 


I C2 J o pbl o b 
O Uy o (c 7 ). 


idi 


ttrue o Ux o (c 1) o Uy o (c 20) Ux o (c 0) 


2 . Now; we rewrite the rule (copairi), and handle [ idi | cs o untag e ] o 
ini o (ipi ttrue Cj) o [ [ ]i o tag e | C2 ] o pbl o b o Ux o (c 1) o Uy o 
(c 20 ) =~ Ux o (c 0 ). By unfolding b, we get [ idi | C3 o untag e ] o ini 
o (ipi ttrue Cj) o [ [ ]i o tag e | C2 ] o pbl o (tpure <=) o (lx (c 0)) 

o Ux o (c 1) o Uy o (c 20 ) =~ Ux o (c 0) o Uy o (c 7 ). With the help of 

lemma commutation— lookup— constant— update, we obtain [ idi | C3 
o untag e ] oinl o (ipi ttrue Ci) o [ [ ]i o tag e | C2 ] o pbl o (tpure 

<=) o ((c 1 ), (c 0 )) o Ux o (c 1 ) o Uy o (c 20 ) =~ Ux o (c 0 ) o Uy o (c 7 ). 

The rule (imp2) gives [ idi | C3 o untag e ] o ini o (Ipi ttrue ci) o 
[ [ ]i o tag e I C2 ] o ffalse o Ux o (c 1) o Uy o (c 20) Ux o (c 0) 
o Uy. o (c 7 ). We now rewrite (copair2) [ idi | C3 o untag e ] o ini 
o (ipi ttrue ci) o C2 o Ux o (c 1) o Uy o (c 20) Ux o (c 0) o Uy o 
(c 7 ). Here, we unfold C2, [ idi | C3 o untag e ] o ini o (ipi ttrue Ci) 
o Ux o (tpure —) o (lx, (c 1)) o Ux o (c 1) o Uy o (c 20) =~ Ux o (c 0) 
o Uy o (c 7 ). The lemma commutation — lookup — constant — update 
gives [ idi | C3 o untag e ] o ini o (ipi ttrue Ci) o Ux o (tpure —) o 
((c 1), (c 1)) o Ux o (c 1) o Uy o (c 20) =~ Ux o (c 0) o Uy o 0 (c 7 ). We 
rewrite (impi) and then get [ idi | C3 o untag e ] o ini o (ipi ttrue ci) 
o Ux o (c 0) Ux o (c 1) o Uy o (c 20) =~ Ux o (c 0) o Uy o (c 7 ). We again 
rewrite the lemma commut at ion-update-update and obtain [ idi | C3 o 
untag e ] o ini o (ipi ttrue Ci) o Ux o (c 0) o Uy o (c 20) =~ UxO (c 0) 
o Uy o (c 7 ). 


3. We re-iterate the loop via (imp-loopiter) with Ux o (c 0) o Uy o (c 20): [ 
idi I C 3 o untag e ] o ini o [(ipi ttrue Ci) o ci | id ] o ttrue o Ux o (c 0) 
o Uy o (c 20) Ux o (c 0) o Uy o (c 7). We first rewrite (copairi) and 
unfold ci: [ idi | C 3 o untag e ] o ini o (ipi ttrue Ci) o [ throw el [ 02 ] 
o pbl o (tpure <=) o (lx, (c 0)) o Ux o (c 0) o Uy o (c 20) =~ Ux o (c 0) 
o Uy o (c 20). By rewriting commutation — lookup — constant — update 
and (impa), the comparison yields in ttrue. So that: [ idi | 03 o untag 
e ] o ini o (ipi ttrue ci) o [ throw e 1 | C 2 ] o ttrue o Ux o (c 0) 
o Uy o (c 20) Ux o (c 0) o Uy o (c 20). By (copairi), the exception 
is thrown: [ idi | C 3 o untag e ] o ini o ((ipi ttrue Ci) o throw e 
1 ) o Ux o (c 0) o Uy o (c 20) Ux o (c 0) o Uy o (c 20). Now; via 
interaction-propagator-throw, we get [ idi | C 3 o untag e ] o ini o 
( throw e 1 ) o Ux o (c 0) o Uy o (c 20) =~ Ux o (c 0) o Uy o (c 20). 

4. Here, we first unfold throw: [ idi | C 3 o untag e ] o ini o [ ]i o tag e o Ux o 
(c 0 ) o Uy o (c 20 ) =~ Ux o (c 0 ) o Uy o (c 20 ) then, cut ini o [ ]i == inr. 
Thus, we have [ idi | C 3 o untag e ] o inr o tag e o Ux o (c 0 ) o Uy o 
(c 20) =~ Ux o (c 0 ) o Uy o (c 7). By (copair 2 ), C 3 o untag e o tag e o 
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Ux o (c 0) o Uy o (c 20) Ux o (c 0) o Uy o (c 7). Since Ux o (c 0) o Uy o 
(c 20) is pure up to the exception, we rewrite (eaxi) to get C3 o Ux o (c 0) 
o Uy o (c 20) Ux o (c 0) o UyO (c 7). If follows C3 = (uy o (c 7)) that 
Uy o (c 7) o Ux o (c 0) o Uy o (c 20) =~ UxO (c 0) o Uy o (c 7). We now 
rewrite commutation— update— update on the left to have Ux o (c 0) o 
Uy o (c 7) o Uy o (c 20) Ux o (c 0) o Uy o (c 7). Finally, it suffices to 
rewrite interaction— update—update, Ux o (c 0) o Uy o (c 7) =~ Ux o 
(c 0) o Uy o (c 7). It still remains to prove that ini o [ == inr: since 
everything is pure up to the exception, we have ini o [ inr. Now, 

(unit...,) suffices to have [ ]i+i =~ [ ]i+i. 


□ 

The complete Coq library with all certified proofs can be found on https://forge.imag.fr/frs/downioad.php/65i/iMP-sTATEs 

7 Conclusion 

We have presented new frameworks for formalizing the treatment of the state 
and the exception via the decorated logic both separately and combined with 
Coq implementations. Decorations form a bridge between the syntax and the 
interpretation by turning the syntax sound without adding any explicit type of 
the state nor the exception. Combined setting is specialized for the IMP-|-Exc 
language and finally equivalence proofs of programs are given with related cer¬ 
tifications in Coq. Besides, in [5], we prove that the core language for the 
state and exception as well as the programmers’ language for the exception are 
complete. 
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